docs/TEMPLATES.md (2)

67-68: Fix bare URLs for better markdown rendering.

The URLs on these lines should be wrapped in angle brackets <> or converted to proper markdown links for better rendering and to comply with markdown linting standards.

Based on learnings

Apply this diff:

 **Access:**
-- Apache: http://localhost
-- phpMyAdmin: http://localhost/phpmyadmin
+- Apache: <http://localhost>
+- phpMyAdmin: <http://localhost/phpmyadmin>

---

318-331: Add language identifier to code fence.

The code fence starting at line 319 should specify a language identifier (e.g., text or console) for proper syntax highlighting and to comply with markdown standards.

Based on learnings

Apply this diff:

 Output:
-```
+```text
 📋 Available Templates:

cortex/templates/ml-ai.yaml (3)

25-33: Consider version pinning for ML libraries to ensure compatibility.

Installing TensorFlow, PyTorch, and other ML libraries without version constraints can lead to:

1. Dependency conflicts between TensorFlow and PyTorch
2. Breaking changes in newer versions
3. Incompatible transitive dependencies
4. Non-reproducible installations

Consider specifying compatible version ranges:

-  - command: pip3 install numpy pandas scipy matplotlib scikit-learn jupyter notebook
+  - command: pip3 install numpy pandas scipy matplotlib scikit-learn jupyter notebook
     description: Install core ML libraries
     requires_root: false
-  - command: pip3 install tensorflow torch torchvision torchaudio
+  - command: pip3 install tensorflow>=2.12.0,<3.0.0 torch>=2.0.0,<3.0.0 torchvision torchaudio
     description: Install deep learning frameworks
     requires_root: false

---

28-30: Add timeout or split large package installations.

Installing TensorFlow and PyTorch together can take a very long time and consume significant bandwidth (multiple GB). Consider:

1. Adding timeout handling
2. Splitting into separate steps for better progress feedback
3. Warning users about installation time and size

Split the installation for better UX:

-  - command: pip3 install tensorflow torch torchvision torchaudio
-    description: Install deep learning frameworks
+  - command: pip3 install tensorflow
+    description: Install TensorFlow (this may take several minutes)
+    requires_root: false
+  - command: pip3 install torch torchvision torchaudio
+    description: Install PyTorch (this may take several minutes)
     requires_root: false

---

46-47: Simplify post-install verification commands.

The complex shell commands with error redirection and fallbacks in post_install may fail silently or produce confusing output.

Simplify the commands:

-  - echo "TensorFlow: $(python3 -c 'import tensorflow as tf; print(tf.__version__)' 2>/dev/null || echo 'installed')"
-  - echo "PyTorch: $(python3 -c 'import torch; print(torch.__version__)' 2>/dev/null || echo 'installed')"
+  - python3 -c "import tensorflow as tf; print(f'TensorFlow: {tf.__version__}')" || echo "TensorFlow: import failed"
+  - python3 -c "import torch; print(f'PyTorch: {torch.__version__}')" || echo "PyTorch: import failed"

test/test_templates.py (1)

1-1: Make test file executable or remove shebang.

The file has a shebang (#!/usr/bin/env python3) but is not marked as executable. Either make it executable or remove the shebang.

Make the file executable:

chmod +x test/test_templates.py

Or remove the shebang if the file is only meant to be run via pytest/unittest.

cortex/templates/mean.yaml (1)

1-64: Consider template refactoring to reduce duplication.

The MEAN and MERN templates share significant structure:

• Same Node.js setup process (lines 13-21)
• Same MongoDB installation (lines 25-35)
• Similar verification commands

While templates should remain self-contained for clarity, consider documenting common patterns or creating template composition capabilities in future iterations to reduce maintenance burden.

cortex/templates/devops.yaml (1)

1-93: DevOps template structure looks solid; only minor consistency nit

The template fields (metadata, packages, steps, hardware_requirements, post_install, verification_commands, metadata) line up with the Template/InstallationStep model and should round‑trip cleanly through Template.from_dict/TemplateValidator. The requires_root flags also correctly mark privileged operations.

One optional improvement: the packages list is more conceptual, while the actual installation is driven by the explicit steps (e.g., Docker installed via the official repo as docker-ce, not docker.io). If you want history and UX to reflect the exact packages that were installed, you could either (a) align packages with the concrete packages used in the steps, or (b) leave packages empty for step‑driven templates and let history derive packages from the commands instead. Not required, but it would remove a small source of confusion when inspecting installation records.

cortex/cli.py (4)

299-304: Minor polish: avoid placeholder-free f-strings

There are a couple of f-strings that don’t interpolate anything (e.g., print(f"\n[WARNING] Hardware Compatibility Warnings:") and print("\n(Dry run mode - commands not executed)") vs print(f"\n(Dry run mode - commands not executed)")). These trigger Ruff F541 and can just be plain strings:

-                print(f"\n[WARNING] Hardware Compatibility Warnings:")
+                print("\n[WARNING] Hardware Compatibility Warnings:")
@@
-                print(f"\n(Dry run mode - commands not executed)")
+                print("\n(Dry run mode - commands not executed)")

This is cosmetic only, but it quiets the linter and clarifies intent.

Also applies to: 339-344

---

479-535: Improve robustness of interactive template_create

The interactive template_create flow works, but a couple of small tweaks would make it more robust:

• You re-import Template and HardwareRequirements inside the method even though they’re already imported at module level.
• Converting hardware requirement inputs directly with int() will raise ValueError on non-numeric input and surface as a generic “Failed to create template” error.

You could simplify and harden this block like:

-                # Create template
-                from cortex.templates import Template, HardwareRequirements
-                template = Template(
+                # Create template
+                template = Template(
                     name=name,
                     description=description,
                     version=version,
                     author=author,
                     packages=packages
                 )
@@
-                if min_ram or min_cores or min_storage:
-                    hw_req = HardwareRequirements(
-                        min_ram_mb=int(min_ram) if min_ram else None,
-                        min_cores=int(min_cores) if min_cores else None,
-                        min_storage_mb=int(min_storage) if min_storage else None
-                    )
-                    template.hardware_requirements = hw_req
+                if min_ram or min_cores or min_storage:
+                    try:
+                        hw_req = HardwareRequirements(
+                            min_ram_mb=int(min_ram) if min_ram else None,
+                            min_cores=int(min_cores) if min_cores else None,
+                            min_storage_mb=int(min_storage) if min_storage else None,
+                        )
+                        template.hardware_requirements = hw_req
+                    except ValueError:
+                        self._print_error("Hardware requirements must be integers (MB/cores).")
+                        return 1

This avoids a surprising stack trace for a simple input typo and removes an unnecessary re-import.

---

619-640: Argparse wiring for template subcommands is correct; minor cleanup

The CLI wiring for template subcommands and install --template looks good and should behave as documented. A couple of nits from static analysis:

• template_list_parser is assigned but never used; you can drop the variable and just call add_parser(...).
• The template dispatch block is exhaustive; the final else branch printing template_parser.print_help() is fine.

Example cleanup:

-    # Template list
-    template_list_parser = template_subparsers.add_parser('list', help='List all available templates')
+    # Template list
+    template_subparsers.add_parser('list', help='List all available templates')

Functionally everything is sound; this just reduces a tiny bit of dead code and silences Ruff’s F841 warning.

Also applies to: 649-673

---

59-76: Template-aware install flow is consistent with existing behavior

The updated install method short-circuits to _install_from_template when template is provided, and the CLI entrypoint correctly passes an empty software string only in that case:

• When --template is set, install does not touch the LLM path or the software argument, so the empty string is harmless.
• When software is given without --template, the original LLM-driven flow is preserved.

There is a tiny bit of duplication (InstallationHistory() and start_time are created even when immediately delegating to _install_from_template), but that’s just an efficiency nit and not worth complicating the control flow right now.

Also applies to: 649-657

cortex/templates.py (2)

428-452: Reuse the existing PackageManager instead of instantiating a new one

TemplateManager.__init__ already creates self._package_manager = PackageManager(), but generate_commands ignores it and instantiates a new PackageManager:

elif template.packages:
    # Use package manager to generate commands
    pm = PackageManager()
    package_list = " ".join(template.packages)
    try:
        commands = pm.parse(f"install {package_list}")

This is minor, but it means you re-run package manager detection and mappings unnecessarily. You can simplify and avoid redundant work by reusing the existing instance:

-        elif template.packages:
-            # Use package manager to generate commands
-            pm = PackageManager()
-            package_list = " ".join(template.packages)
+        elif template.packages:
+            # Use the existing package manager to generate commands
+            pm = self._package_manager
+            package_list = " ".join(template.packages)

Functionally it’s equivalent, but keeps initialization centralized and slightly reduces overhead when generating commands from templates.

---

151-156: Annotate TemplateValidator.REQUIRED_FIELDS/REQUIRED_STEP_FIELDS as ClassVar

Ruff correctly points out that the mutable class attributes in TemplateValidator should be annotated as ClassVar to make their intent clear and avoid confusion with instance fields:

-from typing import Dict, List, Optional, Any, Set, Tuple
+from typing import Dict, List, Optional, Any, Set, Tuple, ClassVar
@@
 class TemplateValidator:
@@
-    REQUIRED_FIELDS = ["name", "description", "version"]
-    REQUIRED_STEP_FIELDS = ["command", "description"]
+    REQUIRED_FIELDS: ClassVar[List[str]] = ["name", "description", "version"]
+    REQUIRED_STEP_FIELDS: ClassVar[List[str]] = ["command", "description"]

This doesn’t change runtime behavior but makes the dataclass/linter story cleaner and documents that these are shared constants, not per-instance state.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

cortex/templates/ml-ai.yaml (1)

35-41: GPU/CUDA recommendation is descriptive only (no compatibility check).

With requires_gpu: false and requires_cuda: false, the hardware compatibility logic in TemplateManager.check_hardware_compatibility will never emit GPU/CUDA warnings for this template, even though the description recommends a GPU for deep learning. That’s fine if GPU is truly optional, but if you want the CLI to surface a warning when no suitable GPU/CUDA is detected (while still allowing users to continue), consider setting the GPU/CUDA flags and a minimal CUDA version so the checker can report that guidance programmatically.

cortex/cli.py (5)

345-380: Add a progress callback for step-based template executions.

When template.steps is present you build a plan and call InstallationCoordinator.from_plan(...) without a progress_callback, so template-based installs with explicit steps won’t show per-step progress, while the fallback branch using InstallationCoordinator(...) does.

For consistent UX, consider wiring a progress callback into the from_plan call similar to the non-steps branch, e.g., defining a local progress_callback and passing it as a keyword argument.

---

394-400: Post-install commands executed via shell=True on template content.

template.post_install entries are executed with subprocess.run(cmd, shell=True). Given these commands are template-controlled (and potentially user-imported), this is powerful and expected, but it also means any imported template effectively has arbitrary shell execution rights when --execute is used.

If you want a safer default, you could:

• Reserve shell=True only for commands that truly need shell features, or
• Treat post-install purely as informational (e.g., echo text parsed and printed via Python) and move “real” commands into steps where you might later add richer controls.

Not a blocker, but worth consciously documenting as part of the trust model for templates.

---

448-471: Template CLI commands use broad except Exception; consider narrowing or surfacing more detail.

template_list, template_create, and template_import/template_export all wrap their bodies in except Exception as e, which is flagged by static analysis and can hide useful distinctions between user errors (bad paths, invalid formats) and actual bugs.

Consider:

• Catching more specific exceptions where possible (e.g., FileNotFoundError, ValueError, OSError), and
• Letting unexpected exceptions bubble up to the outer main() handler, or at least re‑raising after logging for debugging.

This improves debuggability without changing behavior for expected user-facing failures.

---

618-619: Remove unused template_list_parser variable to satisfy linting.

template_list_parser is assigned but never used; Ruff flags this as F841. Since you don’t need the parser reference later, you can drop the binding:

-    # Template list
-    template_list_parser = template_subparsers.add_parser('list', help='List all available templates')
+    # Template list
+    template_subparsers.add_parser('list', help='List all available templates')

---

643-651: Ambiguous combination of software and --template arguments.

In main(), if both args.template and args.software are provided, the args.template branch wins and software is ignored. That’s reasonable, but it’s implicit.

If you expect users might accidentally mix modes, consider rejecting that combination explicitly (e.g., print an error when both are set) or documenting that --template takes precedence.

cortex/templates.py (2)

436-459: Reuse the existing PackageManager instance in generate_commands.

You already construct self._package_manager in __init__, but generate_commands instantiates a new PackageManager each time. To avoid redundant detection and configuration, you can reuse the existing instance:

-        elif template.packages:
-            # Use package manager to generate commands
-            pm = PackageManager()
-            package_list = " ".join(template.packages)
+        elif template.packages:
+            # Use shared package manager to generate commands
+            pm = self._package_manager
+            package_list = " ".join(template.packages)

The rest of the logic (parse + fallback) can remain unchanged.

---

299-324: Silent swallowing of malformed built-in templates.

In list_templates, malformed built-in templates are caught with except Exception: pass. This keeps listing robust if one template is broken, but it also hides which template failed and why.

If you’d like more visibility without breaking UX, consider logging these exceptions at a debug or warning level (or at least including the filename in a diagnostic message) instead of fully suppressing them.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

cortex/cli.py (3)

444-448: Consider more granular error handling and explicit f-string conversion.

The broad exception tuple on line 444 might mask unexpected errors. While reasonable for a CLI tool, consider logging the exception type to aid debugging.

Apply this diff for better observability:

-        except (RuntimeError, OSError, subprocess.SubprocessError) as e:
+        except (RuntimeError, OSError, subprocess.SubprocessError) as e:
+            logger.debug(f"Exception type: {type(e).__name__}")
             if install_id:
                 history.update_installation(install_id, InstallationStatus.FAILED, str(e))
-            self._print_error(f"Unexpected error: {str(e)}")
+            self._print_error(f"Unexpected error: {e!s}")
             return 1

The !s conversion flag (line 447) makes the string conversion explicit, as suggested by static analysis.

---

471-472: Optional: Add logging to broad exception handlers for debugging.

The template management methods catch broad exceptions (lines 471, 533, 549, 563) to provide user-friendly error messages. While appropriate for a CLI, consider adding debug logging to preserve stack traces for troubleshooting.

Example pattern for one method (apply similarly to others):

+import logging
+
+logger = logging.getLogger(__name__)
+
         except Exception as e:
+            logger.exception("Template operation failed")  # Logs full traceback at DEBUG level
-            self._print_error(f"Failed to list templates: {str(e)}")
+            self._print_error(f"Failed to list templates: {e!s}")
             return 1

Also use explicit !s conversion flags as suggested by static analysis (lines 472, 533, 550, 564).

Also applies to: 532-533, 549-550, 563-564

---

116-168: Consider extracting shared installation execution logic.

The installation execution flow in both install (lines 116-168) and _install_from_template (lines 347-432) contains significant duplication:

• Coordinator creation and execution
• Result handling (success/failure paths)
• History recording
• Progress callbacks
• Error messages

Consider extracting the common logic into a helper method:

def _execute_installation(
    self,
    commands: List[str],
    descriptions: List[str],
    install_id: Optional[str],
    history: InstallationHistory,
    software_name: str,
    verification_commands: Optional[List[str]] = None,
    post_install_commands: Optional[List[str]] = None,
    coordinator_plan: Optional[List[Dict[str, str]]] = None
) -> int:
    """Common installation execution logic."""
    
    def progress_callback(current, total, step):
        status_emoji = "⏳"
        if step.status == StepStatus.SUCCESS:
            status_emoji = "✅"
        elif step.status == StepStatus.FAILED:
            status_emoji = "❌"
        print(f"\n[{current}/{total}] {status_emoji} {step.description}")
        print(f"  Command: {step.command}")
    
    # Create coordinator
    if coordinator_plan:
        coordinator = InstallationCoordinator.from_plan(coordinator_plan, timeout=300, stop_on_error=True)
    else:
        coordinator = InstallationCoordinator(
            commands=commands,
            descriptions=descriptions,
            timeout=300,
            stop_on_error=True,
            progress_callback=progress_callback
        )
    
    print("\nExecuting commands...")
    result = coordinator.execute()
    
    if result.success:
        # Run verification if provided
        if verification_commands:
            self._print_status("[*]", "Verifying installation...")
            verify_results = coordinator.verify_installation(verification_commands)
            # ... verification logic
        
        # Run post-install if provided
        if post_install_commands:
            self._print_status("[*]", "Running post-installation steps...")
            # ... post-install logic
        
        self._print_success(f"{software_name} ready!")
        print(f"\nCompleted in {result.total_duration:.2f} seconds")
        
        if install_id:
            history.update_installation(install_id, InstallationStatus.SUCCESS)
            print(f"\n📝 Installation recorded (ID: {install_id})")
            print(f"   To rollback: cortex rollback {install_id}")
        return 0
    else:
        # Failure handling...
        if install_id:
            history.update_installation(install_id, InstallationStatus.FAILED, result.error_message or "Installation failed")
        # ... error messages
        return 1

Then both methods can call this helper, reducing duplication by ~50 lines while maintaining readability.

Also applies to: 347-432

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

cortex/cli.py (1)

652-656: Consider making software parameter optional in install() method.

The routing passes an empty string "" for software when using --template, which is awkward. Since the method already handles templates via a separate parameter, consider making software optional:

-    def install(self, software: str, execute: bool = False, dry_run: bool = False, template: Optional[str] = None):
+    def install(self, software: Optional[str] = None, execute: bool = False, dry_run: bool = False, template: Optional[str] = None):

Then update the routing:

         if args.command == 'install':
             if args.template:
-                return cli.install("", execute=args.execute, dry_run=args.dry_run, template=args.template)
+                return cli.install(execute=args.execute, dry_run=args.dry_run, template=args.template)
             else:
                 # software is guaranteed to be set due to mutually_exclusive_group(required=True)
                 return cli.install(args.software, execute=args.execute, dry_run=args.dry_run)

This makes the API clearer and eliminates the placeholder empty string.

cortex/templates.py (3)

154-163: Annotate class-level constants with ClassVar for type safety.

Static analysis correctly identifies that class attributes REQUIRED_FIELDS, REQUIRED_STEP_FIELDS, ALLOWED_POST_INSTALL_COMMANDS, and DANGEROUS_SHELL_CHARS should be annotated with typing.ClassVar to indicate they are class-level constants, not instance attributes.

+from typing import ClassVar
+
 class TemplateValidator:
     """Validates template structure and content."""
     
-    REQUIRED_FIELDS = ["name", "description", "version"]
-    REQUIRED_STEP_FIELDS = ["command", "description"]
+    REQUIRED_FIELDS: ClassVar[List[str]] = ["name", "description", "version"]
+    REQUIRED_STEP_FIELDS: ClassVar[List[str]] = ["command", "description"]
     
     # Allowed post_install commands (whitelist for security)
-    ALLOWED_POST_INSTALL_COMMANDS = {
+    ALLOWED_POST_INSTALL_COMMANDS: ClassVar[Set[str]] = {
         'echo',  # Safe echo commands
     }
     
     # Dangerous shell metacharacters that should be rejected
-    DANGEROUS_SHELL_CHARS = [';', '|', '&', '>', '<', '`', '\\']
+    DANGEROUS_SHELL_CHARS: ClassVar[List[str]] = [';', '|', '&', '>', '<', '`', '\\']

---

321-323: Chain exception for better error diagnostics.

Use raise ... from e to preserve the original exception's traceback, which aids debugging when template loading fails.

         except Exception as e:
-            raise ValueError(f"Failed to load template {name}: {str(e)}")
+            raise ValueError(f"Failed to load template {name}: {str(e)}") from e

---

558-559: Chain exception for better error diagnostics.

Use raise ... from e to preserve the original exception's traceback when template import fails.

         except Exception as e:
-            raise ValueError(f"Failed to import template: {str(e)}")
+            raise ValueError(f"Failed to import template: {str(e)}") from e

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

cortex/cli.py (1)

297-408: Fix minor f-string lint and harden post_install execution against shell injection

Two separate points in this block:

1. Extraneous f-string (Ruff F541)
   Line [300] uses print(f"\n Packages:") with no interpolation. This triggers F541 and is trivially fixed:

-            print(f"\n   Packages:")
+            print("\n   Packages:")

2. subprocess.run(..., shell=True) on template-supplied post_install commands remains unsafe
   Lines [402–407] execute every template.post_install entry via subprocess.run(cmd, shell=True). Even with validator constraints, this is effectively running untrusted template content through a shell and is still vulnerable to injection (e.g., via echo $(...) patterns allowed by the validator, as noted in a prior review).

For post‑install informational messages, you can avoid invoking a shell entirely by parsing and printing the echo content in Python instead:

-                    # Run post-install commands once
-                    if template.post_install:
-                        self._print_status("[*]", "Running post-installation steps...")
-                        print("\n[*] Post-installation information:")
-                        for cmd in template.post_install:
-                            subprocess.run(cmd, shell=True)
+                    # Render post-install info without spawning a shell
+                    if template.post_install:
+                        self._print_status("[*]", "Running post-installation steps...")
+                        print("\n[*] Post-installation information:")
+                        for cmd in template.post_install:
+                            stripped = cmd.strip()
+                            if stripped.startswith("echo "):
+                                # Remove leading "echo" and optional surrounding quotes
+                                message = stripped[5:].strip()
+                                if len(message) >= 2 and message[0] == message[-1] and message[0] in ("'", '"'):
+                                    message = message[1:-1]
+                                print(f"  {message}")
+                            else:
+                                print(f"  [WARNING] Skipping non-echo post-install command: {cmd[:80]}")

If you truly need to support non-echo commands, they should be validated much more strictly and executed with shell=False using argument lists rather than passing raw strings to the shell.

#!/bin/bash
# Verify remaining uses of shell=True on template-driven commands
rg -n "post_install" -n cortex
rg -n "shell=True" cortex

cortex/cli.py (5)

65-82: Template routing in install() is functionally correct but adds to an already complex method

The early if template: return self._install_from_template(...) branch correctly preserves existing LLM-based behavior and routes template installs through their own workflow.

However, Sonar is already flagging install() for high cognitive complexity, and this change nudges it further. Consider extracting the LLM-based path into a dedicated helper (e.g., _install_via_llm(...)) and keeping install() as a thin router between template and non-template flows. This would also let you avoid initializing InstallationHistory and start_time when the template branch is taken but never uses them.

---

322-444: Template installation flow is sound but very large; consider breaking into smaller helpers

The overall control flow in _install_from_template() (load template → show metadata → hardware check with prompt → generate commands → history record → dry‑run/execute → verification → post‑install → history update) looks correct and user‑friendly.

That said, Sonar flags this method for very high cognitive complexity. It’s now handling:

• Hardware compatibility prompting and non-interactive aborts
• Command generation and display
• Two execution strategies (template steps plan vs. raw commands)
• Verification reporting
• History bookkeeping and error handling

To make this maintainable, consider splitting into focused helpers, e.g.:

• _prompt_hardware_acceptance(template, is_compatible, warnings, dry_run)
• _build_coordinator_for_template(template, commands)
• _run_template_verification(coordinator, template)
• _record_and_print_result(history, install_id, result, template)

This would also let you share pieces (e.g., progress callbacks and history updates) with the LLM-based install() path.

---

456-479: template_list() behavior looks good; keep broad exception catching minimal

Listing and formatting of templates (name/version/type/description, capped width) is straightforward and matches expectations. The broad except Exception as e with self._print_error(f"Failed to list templates: {str(e)}") is acceptable for a CLI surface, but if you find yourself duplicating this pattern across multiple template helpers, it may be worth centralizing into a small _handle_cli_error(context: str, exc: Exception) to reduce repetition and complexity.

Also, to satisfy Ruff RUF010 you can simplify to f"{e}" instead of f"{str(e)}".

---

481-545: Interactive template_create() flow is user-friendly; complexity is creeping up

The interactive creation flow (description/version/author → packages loop → optional hardware requirements → save) is clear and matches the PR’s goals. Numeric validation for hardware requirements with a targeted ValueError handler is a nice improvement.

Sonar, however, flags this method for high cognitive complexity. To keep it manageable, consider extracting small helpers, for example:

• _prompt_template_metadata(name) -> (description, version, author)
• _prompt_packages() -> List[str]
• _prompt_hardware_requirements() -> Optional[HardwareRequirements]

This would also make it easier to add a non-interactive path in the future without overloading this single method.

---

546-575: Import/export helpers look correct and straightforward

template_import() and template_export() are thin wrappers over TemplateManager, correctly wiring up file paths, names, formats, and user messaging. The behavior matches the documented CLI (cortex template import ... / export ...).

Only minor nit (optional): you could again simplify str(e) inside the f-strings to just {e} or {e!s} to appease Ruff’s RUF010 and keep exception formatting consistent across methods.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

cortex/cli.py (1)

509-514: Security: shell=True with template-sourced commands enables command injection.

The post_install commands from templates are executed with shell=True, which can execute arbitrary shell code. Even if templates restrict to echo, command substitution like echo $(malicious_cmd) will execute.

Parse and print echo messages directly in Python to eliminate shell execution:

                     # Run post-install commands once
                     if template.post_install:
                         self._print_status("[*]", "Running post-installation steps...")
                         print("\n[*] Post-installation information:")
                         for cmd in template.post_install:
-                            subprocess.run(cmd, shell=True)
+                            # Safely extract and print echo messages without shell
+                            cmd_stripped = cmd.strip()
+                            if cmd_stripped.startswith('echo '):
+                                message = cmd_stripped[5:].strip('\'"')
+                                print(f"  {message}")
+                            else:
+                                print(f"  [WARNING] Skipped non-echo post-install command")

cortex/cli.py (3)

186-207: Redundant API key retrieval.

When template is None, lines 186-192 already fetch and validate api_key and provider, but lines 204-207 fetch them again unconditionally after the template check.

Remove the duplicate fetch since validation already occurred:

             # If template is specified, use template system
             if template:
                 return self._install_from_template(template, execute, dry_run)
             # Otherwise, use LLM-based installation
-            api_key = self._get_api_key()
-            if not api_key:
-                return 1
-            provider = self._get_provider()
+            # api_key and provider already fetched above (lines 186-191)
             self._print_status("🧠", "Understanding request...")

---

384-561: Consider splitting this method to reduce complexity.

SonarCloud flags Cognitive Complexity of 85 (limit: 15). This method handles template loading, hardware checks, command generation, execution, verification, and post-install steps.

Extract focused helper methods:

def _install_from_template(self, template_name: str, execute: bool, dry_run: bool):
    """Install from a template."""
    template = self._load_and_validate_template(template_name)
    if not template:
        return 1
    
    if not self._check_template_hardware(template, dry_run):
        return 1
    
    commands = self._prepare_template_commands(template)
    if not commands:
        return 1
    
    return self._execute_template_install(template, commands, execute, dry_run)

This improves testability and maintainability.

---

611-618: Remove redundant local import.

Template is already imported at line 17. HardwareRequirements should be added to the top-level import instead of importing locally.

Update the top-level import and remove the local one:

-from cortex.templates import TemplateManager, Template, TemplateFormat, InstallationStep
+from cortex.templates import TemplateManager, Template, TemplateFormat, InstallationStep, HardwareRequirements

Then remove line 611:

                 # Create template
-                from cortex.templates import Template, HardwareRequirements
                 template = Template(

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro